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Abstract. Concept design plays a central role in project success as its product effectively locks the 
majority of system life cycle cost. Such extraordinary leverage presents a business case for 
conducting concept design in a credible fashion, particularly for first-of-a-kind systems that 
advance the state of the art and that have high design uncertainty. A key challenge, however, is to 
know when credible design convergence has been achieved in such systems. Using a space system 
example, this paper characterizes the level of convergence needed for concept design in the context 
of technical and programmatic resource margins available in preliminary design and highlights the 
importance of design and cost evaluation learning curves in determining credible convergence. It 
also provides techniques for selecting trade study cases that promote objective concept evaluation, 
help reveal unknowns, and expedite convergence within the trade space and conveys general 
practices for conducting effective concept design-to-cost studies. 

Preface 

Concept design may be conducted using a variety of methods, some more efficient and effective 
than others. Using a space observatory example, this paper describes some of the more strategic 
aspects of one process for conducting comprehensive concept design and design-to-cost trade 
studies. This process is best suited for studying immature (e.g., first-of-a kind) mission concepts 
that advance the state of the art and that have high design uncertainty. Aspects discussed include: 
a) what concept design is and why it is important, b) the fidelity needed in the concept design 
solution, c) techniques for designing the mission level trade space, and d) challenges in determining 
credible design convergence. 

What Concept Design is and Why it is Important 

Concept design typically is conducted to determine a “feasible” system level design baseline for a 
new concept, as described in par. 5.3 of ref. (a). An exploratory process, it is as much about 
investigating requirements as it is about investigating design. More specifically for space missions, 
it involves a concurrent investigation of multiple mission characteristics such as design, 
performance, concept of operations (CONOPS), flight dynamics, technology development, 
verification approach, launch and ground station interfaces, mission and science operations centers, 
cost, schedule, and risk. 


Figure 1 shows Pre-Phase A and Phase A of the NASA project life cycle are used to develop the 
concept design. Phase B is used to develop the preliminary design, and Phase C, up to Critical 
Design Review (CDR), is used to develop the detailed (or final) design. The post-CDR portion of 


Phase C is used to fabricate system elements and prepare for their physical integration. 
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Figure 1: The NASA Project Life Cycle (ref. (b)) 


Concept Design Determines Majority of Life Cycle Costs. The earliest life cycle phases have 
the most leverage over life cycle cost. This is conceptually illustrated in Fig. 2, which shows by 



Figure 2: The Majority of Life Cycle Costs are Locked by Concept Design 1 

completion of concept design the majority of project life cycle cost has been fixed (or rendered 
unchangeable) for a given design. Such extraordinary leverage presents a business case for 
conducting concept design in a rigorous and pragmatic fashion, particularly for immature mission 
concepts that advance the state of the art and that have high design uncertainty. 

Done well, concept design can provide an executable system level design baseline for project teams 
in Phase B and later phases. Done poorly, it can lead to several undesirable outcomes for project 
teams, such as: a) cost overruns, b) the need for redesign (or for multiple redesigns characterized 
by fluid technical baselines with ever-decreasing capabilities), c) recurring schedule delays, d) 
contract disputes or cancellations, and e) challenges in retaining trained personnel. 

Pre-Phase A and Phase A Offer Unique Venue for System Level Trades. As the design 
progresses from pre-Phase A into Phase C, the scope of design work ranges from broad and shallow 
to narrow and deep. In Pre-Phase A and Phase A, concept design teams conduct broad and shallow 
trade studies to quickly evaluate a range of mission “requirements” 2 and design characteristics 
(R&DC) and make key decisions that determine the final concept design. The concept design 
phases provide an ideal, inexpensive venue for conducting these system level trade studies, as 
teams in these phases typically are small, closely coordinated, and agile in their ability to handle 
high rates of change in system level R&DC. Additionally, concept design teams typically operate 
absent many of the formalities present in later project phases. For example, typically there are no 
prime contracts, and system level requirements typically are not placed under formal configuration 
control until late in Phase A. 

Conversely, Phase B and later phases are not well suited for system level trades. In Phase B, the 
system level design is more difficult and more expensive to change. Typically teams are larger 
and more distributed, prime contracts are in place, and system level requirements are under formal 
configuration control. Preliminary design work assumes the system level concept design is 
complete. In this more formal environment, collateral impacts (e.g., design, cost, contractual) of 
system level changes can become significant considerations, as can the time and effort required to 
conduct the configuration control process. For similar reasons, the system level design is even 
more difficult and more expensive to change during Phases C and D. In Phases C and D, teams 
typically are even larger, system and subsystem level requirements are under formal configuration 
control, and detailed design work either is underway or has been completed. 

Illustrating these points, par. 2.1 of ref. (a) cites the historical data 3 in Fig. 3 and states “NASA 
experience shows a positive correlation between a fully adequate mission design process (PrePhase 
A, Phase A, and Phase B) and a successful Phase C/D”. Paragraph 2.1 of ref. (a) further states “It 
is generally accepted that Phase C/D cost overruns are usually created by a lack of understanding, 
inadequate definition of, and changing requirements.” Reference (a) defines the 


1 Figure 2 is an excerpt from ref. (c) that has been reformatted for presentation in this paper. 

2 In this paper, the term “requirements” is used in an informal context when in quotes to denote interim reference 
capabilities used to guide evaluation of point designs within the trade space. System level requirements are not 
formally baselined until System Requirements Review (SRR) near the end of Phase A for a final concept design that 
meets technical and programmatic (including cost and schedule) constraints. 

3 From ref. (a), Fig. 2-1. A similar figure is published at ref. (d). 



Figure 3: Benefit of Study Phase Investment (ref. (a), Fig. 2-1) 


mission design process as occurring in the study phases, which ref. (a) further defines as prePhase 
A, Phase A, and Phase B. While the content of Fig. 3 is dated, and while the phase definitions in 
ref. (a) differ somewhat from those in Fig. 1 (i.e., in ref. (a), Phase B ends at SDR and does not 
include PDR), the general findings of ref. (a) remain relevant. 

Fidelity Needed in Concept Design Solution 

A Proposed Definition for a “Feasible” Mission Concept. Reference (a), par. 5.3 discusses a 
“feasible” design as one that “falls within mission requirements or budgetary guidelines”. But in 
practice, the use of the term, “feasible”, often is problematic. It is frequently used without 
definition, leaving open to interpretation whether a feasible design needs to be both technically 
feasible as well as cost and schedule constrained to a certain level of confidence, or whether it 
simply needs to be an early analytical proof of concept. The broad range of potential interpretations 
has significant implications on design teams, customers, and stakeholders. 

This paper defines a “feasible” mission concept to mean: 

Technical, cost, and schedule characteristics for a single, baseline mission concept design 
have been credibly converged to the first order by the end of Phase A, such that the design 
may be developed, launched, operated, and decommissioned by a competent project team 
starting in Phase B within customary technical and programmatic margins. 

A Model for Product Fidelity in Design Phases. When conducting concept design, teams, 
customers, and stakeholders may seek an objective measure for required product fidelity to help 
them understand when a concept design study may be considered complete (i.e., to understand 
“how good is good enough?”). Such an objective measure would help avoid determining 
completion simply based on external considerations, such as when time or study funds have been 
exhausted, or such as pressure to meet a milestone on a high visibility, politically important effort. 
But measures for product fidelity tend to be general or qualitative in nature. 


For example, paragraph 4. 4. 1.2 of ref. (e) notes design teams conduct design solution analysis in a 
recursive and iterative fashion to successively increasing levels of refinement and resolution. It 
states “the design effort [proceeds] to a depth that is sufficient to meet several needs: the design 
must penetrate sufficiently to allow analytical validation of the design requirements; it must also 
have sufficient depth to support cost modeling and to convince a review team of a feasible design 
with performance, cost, and risk margins.” Figure 4.4-3 of ref. (e) addresses levels of error or 
uncertainty, but only in a general sense. 

A Proposed Metric for Level of Convergence. In the following paragraphs, a level of 
quantification is introduced for product fidelity that suggests the needed fidelity in product system 
level sizing and performance (SLSP) for the design phases is defined as having credibly achieved: 
a) first order convergence at the end of Phase A, b) second order convergence at the end of Phase 
B, and c) third order convergence at the end of Phase C. Examples of SLSP parameters include 
system level mass and power. 

This needed convergence is illustrated by the solid black, uniform convergence curves in Fig. 4 
(adapted from ref. (a), Fig. 3-4), where allowable SLSP error decreases as the design progresses 
from Phase A through Phase C. Credible convergence to the first order by the end of Phase A 



Figure 4: A Proposed Model for Product Fidelity in Design Phases 


means SLSP of the mission elements has been confidently determined to within 90% (read this as 
accurate to one significant digit, or as 9 x 10 1 %) of what it will be when the flight system is 
delivered, for given cost and schedule constraints. This implies, for example, there is residual 
uncertainty that the design could get larger or smaller by -10%, or that performance could increase 
or decrease by -10%, between the end of Phase A and launch. The solid black curves also depict 
by the end of Phases B and C that SLSP has been confidently determined to the second order, or 


99% (accurate to two significant digits, approximately ±1% error), and to the third order, or 99.9% 
(accurate to three significant digits, approximately ±0.1% error), respectively. 

The metrics for SLSP error in Fig. 4 are intended as approximate guidelines only. They provide a 
coarse model that depicts an idealized trend of fidelity in each phase. Actual convergence may 
appear non-uniform, as also notionally depicted in Fig. 4. An SLSP error in this context typically 
means while sizing or performance calculations were done properly, they were done with 
incomplete or incorrect information and/or assumptions. Implicit in this model is SLSP values at 
the end of Phase C are within the range of possible SLSP values at the end of Phase A. Also 
implicit is SLSP values include contingency quantities typically added to address the uncertainty 
of immature items, such as items that have a low technology readiness level. 

Example SLSP Error Convergence. To visualize an example of SLSP error for mass, consider 
that by the end of Phase A, mass for a 4,000 kg observatory should be known to within 
approximately ± 10%, or ± 400 kg, of its final launch mass. As the design matures in subsequent 
phases, concept phase estimates are replaced by more refined estimates, or by actual flight 
hardware masses. By the end of Phases B and C, mass for a 4,000 kg observatory should be known 
to within approximately ±1% and ±0.1% (or to within approximately ± 40 kg and ± 4 kg), 
respectively, of the final launch mass. 

Role of Resource Margins on Needed Convergence. The needed SLSP error convergence in 
Fig. 4 must be within the envelope of the required design margins. Figure 4 shows examples of 
design margin requirements selected from ref. (f), where power and dry mass margins on flight 
systems are required to be > 25%, > 20%, and> 15% at the end of Phases A, B, and C, respectively. 
Cost and schedule margin requirements apply from ref. (g) as well, though not depicted in Fig. 4. 
For example, ref. (g) requires projects at the start of Phase C to have a budget margin of > 25% 
through Phase D. It also levies as a goal (not a requirement) that projects at the start of Phase B 
have a budget margin of > 30% through Phase D. 

Importance of Concept Design Convergence to Project Managers. Project managers and 
project teams conducting product design and development in Phases B-D rely on having received 
a concept design that has been credibly converged to the first order by the end of Phase A, so they 
can execute their projects within customary allocations for technical, cost, and schedule margins. 4 
To illustrate the effect margins have on required convergence, consider a project manager (PM) 
who receives a completed mission concept design at the start of Phase B. This PM can 
accommodate a concept design that has been credibly converged to within 10% of its flight sizing 
and performance values for power and dry mass resources without redesign, even if the 10% error 
occurs in the direction of needing increased resources, since the mission elements (including the 
launch service) already have been sized to accommodate a 25% growth margin. Conversely, this 
PM cannot accommodate a concept design that has been credibly converged only to within 30% 
of its flight sizing and performance values for power and dry mass, if the 30% error occurs in the 
direction of needing increased resources. The design will likely need to be de-scoped in Phase B 
or later phases. 


4 Margins typically are used to accommodate unforeseen needs or events. 


Techniques for Designing the Mission Level Trade Space 

A design-to-cost trade space such as shown in Fig. 5 can be developed to expedite convergence of 
the concept design. This trade space has axes of mission life cycle cost (referred to here also as 
just “cost”), technical capability, and development schedule. 5 Absent other guidance, each of these 
axes has equal importance, i.e., each can be viewed as one leg of a three-legged stool. 



Figure 5: 3-Cycle Mission Level Concept Design-To-Cost Trade Space 


Figure 5 shows a trade study structured to converge in three discrete design “cycles”. Within the 
trade space, there are two bounding design points, labeled “A” and “B”. The A design reflects a 
realistic “desired” capability. The B design reflects a science or technology “floor” capability, i.e., 
the point below which the mission is no longer compelling from a science or technology 
perspective. An intermediate design point (labeled "C") maximizes technical capability (i.e., 
science or technology return) for the cost and development schedule constraints depicted by the 
solid red lines. 6 The technical capability of the C design is not known at the outset of the study. 
The goal is to credibly determine point C with minimum expended time and effort. 

The approach in Fig. 5 deduces R&DC for the C design by interpolating on the results from the A 
and B designs. It is more like a root finding algorithm than like the spiral (e.g., successive 
refinement 7 ) design processes typically used in Phases B and C. In Phases B and C, each design 
typically is a refinement of the baseline system level design from the prior phase. In the concept 
design process described here, typically there is no baseline system design until the concept design 


5 Figure 5 provides a convenient visualization for depicting design results in the context of key constraints. As 
technical capability is increased, cost and/or schedule typically increase. Alternatively, for a given technical 
capability, a schedule increase may result in a cost increase, etc. 

6 Cost and schedule constraints often are given in request for proposal solicitations. Other constraints may apply as 

well, such as technology readiness, risk, etc. 7 Ref. (e). Fig. 4.4-2 


is complete. While some aspects of the A and B designs may endure in the C design, neither the 
A design nor the B design is intended to represent the final concept design. Instead, the systematic 
process described here is designed to purposely guide the team to view the design problem from 
multiple perspectives. This helps illuminate unexpected findings (e.g., accelerates the discovery 
of “unknown unknowns”) that otherwise may have remained hidden from view. It also quickly 
educates the team on the implications of the bounding “requirements”, stimulates creative thinking, 
and helps mitigate biases while reducing design uncertainty. 

For this discussion, the A design is assumed to be evaluated first. The order of evaluation for the 
first two design points is subject to team preference. There are positive and negative aspects to 
conducting either design first. For example, when the first design is the A design depicted in Fig. 
5, it is also the most complex design. This means the team will be evaluating the most challenging 
design while it is on the steepest part of the learning curve with respect to both the design and the 
study team operation. However, such an A design also may be the most welldefined design point, 
as often it will reflect either the customer’s desired capability or a substantial fraction of that 
capability. Conversely, when the first design is the B design in Fig. 5, the design will be less 
complex. But it also may not be as well defined. Further, the science or technology floor often is 
easier to identify after conducting a design cycle and completing a full cost estimate. Without the 
benefit of a prior cycle to advise on mission cost, the team may not fully recognize the need to 
identify the R&DC for a “true” science or technology floor. 

Selecting R&DC Effectively, Selecting bounding cases is key to this approach, as it allows the 
design team to interpolate within the bounds of its interim study results to select the R&DC for the 
C design. Conversely, failure to select design cycle cases that prove to be bounding can cause the 
team to extrapolate beyond the bounds of its interim study results to determine the R&DC for the 
C design. Extrapolation adds risk in the mission technical, cost, and development schedule 
estimates. The need to extrapolate could occur, for example, if the team selects R&DC for the A 
and B designs that result in each design exceeding cost and schedule constraints. This would 
indicate the team did not take a big enough step down to identify the true science or technology 
floor for the B design (this presumes a solution exists). Alternatively, not reaching the true science 
floor on the B design may incur the need to perform additional design cycles in order to credibly 
determine the R&DC for a final solution that meets cost and schedule constraints. This may be a 
critical failure if the final design is not available by the required deadline, or it may incur team 
overtime. In some instances, teams may find, after exhausting all reasonable options, there is no 
acceptable solution that meets cost and schedule constraints. This is a valid finding that is far less 
costly to learn in concept design than later in the life cycle. 

Optimistic A designs and “false” science floors for B designs are common when establishing the 
R&DC for the A and B designs. The customer (e.g., a scientist / principal investigator) often 
provides a major input into the R&DC for the A and B designs. However, the customer’s vision 
for the A design often is not cost and schedule constrained, as it has not yet been informed by 
rigorous cost and schedule analysis. Further, the customer may resist identifying the true science 
or technology floor for the B design out of concern it may become baselined as the final concept 
design. Teams that recognize, or adapt to, these considerations pragmatically and quickly typically 
will fare better than teams that do not. 


Selecting truly bounding R&DC cases for the A and B designs objectively and without bias will 
help the design team make the best use of its limited design cycles. In a typical case, most (but not 
necessarily all) 7 R&DC parameters: a) reflect a relatively high, but realistic technical capability 
with a relatively long development schedule for the A design, b) reflect a science or technology 
floor with a relatively short development schedule for the B design, and c) are between the A and 
B design R&DC for the C design. The R&DC set for the B design is reevaluated after the A design 
cycle to assure the solution space remains bounded. 

Many parameters vary between the A, B, and C designs, a byproduct of having to conduct a fully 
coupled 9 investigation over a broad solution space in limited time. 8 With such an approach, it may 
appear so many parameters vary between the A, B, and C designs that it will be prohibitively 
difficult to understand the sensitivity of a specific design characteristic to a specific design 
“requirement”. However, experience with this approach on multiple studies at the NASA Goddard 
Space Flight Center has shown teams have been able to gain sufficient understanding of parameter 
sensitivities over the course of a design study. 

Challenges in Determining Credible Design Convergence 

For a design to be considered credibly converged at the end of Phase A, convergence variations 
need to be damped such that SLSP error is sustainably < 10%. One of the most vexing aspects of 
concept design is specifying an objective criterion that indicates the design has credibly converged 
to the first order, because convergence often is evident only in hindsight. This occurs because 
concept design teams learn at a high rate and because design and cost uncertainty is high. As teams 
progress through the design cycles, some of that learning alters the technical, cost, or schedule 
results of prior cycles. 

A subjective criterion is concept design teams normally experience at least a few significant 
surprises, including discovery of significant unknown unknowns, during the course of a study. 
Teams that have not experienced significant surprises should be cautious of their results and should 
recognize the residual risk of discovering significant surprises in later development phases. A lack 
of significant surprises may indicate a team has not sufficiently: a) progressed down the learning 
curve, b) exercised the trade space, or c) mitigated biases. It also may indicate the design did not 
represent a significant advance in the state of the art. Not all surprises will appear in the design. 
For example, utility analyses conducted by science team members may unexpectedly reveal new 
utility in science observations which may alter the science value models in a way that better 
accommodates design constraints or otherwise facilitates the design. 

Why Early Cost Estimates Tend to be Optimistic. A common characteristic of concept design 
is costs for a given design tend to increase with each design cycle. This typically occurs because 
as teams progress through future design cycles, they learn successively more about what may have 
been omitted in previous cycles. Figure 6 notionally illustrates this, where after the B design cycle 
is complete, the cost of the A design increases for a given technical capability. 


7 e.g., R&DC for the B and C cycles may contain selected R&DC parameters from prior cycles, as appropriate 9 The 
use of "fully coupled" means the effects of a “requirement” or a design attribute are assessed concurrently across all 
subsystems for all elements (e.g., spacecraft, instrument, etc.). 

8 After an approach used by Mr. John Oberright, NASA / GSFC Emeritus, for the Space Technology-5 concept design 

study (1999) 



Figure 6: Convergence Determinations Often are Evident Only in Hindsight 


Similarly, after the C design cycle is complete, the cost of the A design increases again, and the 
cost of the B design increases for a given technical capability. Apparent only in hindsight, teams 
should be aware this effect is characteristic of most design studies for immature mission concepts 
that advance the state of the art and that have high design uncertainty. Following the C design 
cycle, this learning tends to taper off for most designs if the A and B designs were bounding cases. 
When schedule increases accompany these cost increases as in Fig. 6, the A and B design points 
move not only to the right, but also into the page. 

Both Design and Work Breakdown Structure (WBS) are Key to Cost Fidelity. Concept 
design teams typically perform cost analysis using multiple methods. One of these methods is 
“grass roots”, which uses a WBS. In this method, each WBS element has a corresponding WBS 
dictionary definition. These definitions, along with team costing ground rules, help teams account 
for costs consistently among mission elements. The WBS dictionary for most space mission 
elements, e.g., spacecraft, launch, ground systems, etc., is largely existing and relatively well 
known. Conversely, the WBS dictionary for a new instrument is unique. It evolves as the 
instrument design evolves. This can be a key factor in estimating costs when the mission concept 
is dominated by a new instrument, as most of the mission development costs may be associated 
with the least well understood mission element. Teams typically need multiple design cycles not 
only to develop a well understood design, but also to develop well understood cost estimates that 
are free of significant gaps and overlaps and that apply team costing ground rules consistently. 
Four Cycle Process. While Figs. 5 and 6 show a three design cycle process, a four cycle process 
may be used when time and resources permit. Using four cycles allows more refined coverage of 
the solution space prior to entering the final ("D") design cycle. That is, completing three points 
prior to the final design offers the opportunity to identify a "knee in the curve", whereas having 
two points provides only linear trends. A four cycle process also allows more opportunities to vary 


subsystem implementation choices and reduces the number of parameters that must be varied 
concurrently in each cycle. 

Additional Recommended Practices for Conducting Mission Concept 

Design Studies 

Treat Design Cycles as a Precious Resource. Design cycles are essential for determining a 
concept design solution, but they are also in limited supply due to the time and manpower available. 
Team efforts should focus on what is needed to directly develop the product and should actively 
limit peripheral tasks and activities. Teams typically should not attempt to retrofit the A and B 
designs with insights gained from the B and C designs, respectively. Time usually is better spent 
just applying learning from the A and B designs to the B and C designs, respectively. Maintaining 
a list of these insights for the A and B designs, however, is often useful. 

First Cost Estimate Should Not be Final Cost Estimate. A team should not let its first cost 
estimate be its final cost estimate. Due to unknown unknowns and learning curve effects, early 
design and cost results may not be as they initially appear. 

Maintain First Order Analysis in Concept Design. Pre-Phase A and Phase A teams evaluate 
multiple designs across a broad trade space in a relatively short period to credibly localize the final 
concept design. Analysis tools typically used are representative to first order precision and agile 
enough to adapt to frequent and significant changes at the system level . 9 By comparison, analysis 
tools typically used in preliminary design (Phase B) are representative to second order precision 
and assume the system level design is stable. Similarly, analysis tools typically used in detailed 
(or final) design (Phase C) are representative to third order precision and assume both the system 
and subsystem level designs are stable. 

A coarse, but useful, analogy is to consider work performed in: a) pre-Phase A and Phase A as 
being done with a hacksaw, b) Phase B as being done with a file, and c) Phase C as being done 
with a polisher. When a team is found using a hacksaw in Phase C, it has done something wrong. 
Such a team did not credibly converge the first order solution by the end of Phase A such that it 
would remain stable in later phases. As a result, the team is having to redo system level concept 
design work late and out of sequence. Similarly, a team found using a polisher in Phase A is doing 
something wrong. Such a team will not move quickly or broadly enough to rough-out and credibly 
converge a first order solution in the time available. Reinforcing this point is some elements of 
early concept designs may not even exist in the final concept design. Polishing these elements can 
result in valuable time lost. 

Avoid Significant Rounding Errors. To avoid masking resource margins, teams typically should 
bookkeep internal design and performance calculations to three significant digits and report results 
to two significant digits . 10 Note that this should not be taken to imply there is three-digit accuracy 
in concept design work. There usually is not. This practice is simply a numerical safeguard to 


9 In some cases, such as new or mission critical technology areas, more in-depth analysis may be selectively warranted 
to reduce cost, technical, or schedule risk. 


10 This is a minimum guideline. 


avoid propagating rounding errors into the second significant digit where these errors potentially 
could overwhelm the ability to adequately determine design or performance margins. 

Computing meaningful design and performance margins in concept design study products depends, 
in part, on having sufficient fidelity in the numerical values used to compute those margins. 
Insufficient fidelity due to rounding errors can overwhelm margin calculations when teams do not 
use sufficient numerical safeguards. For example, consider the two cases below where power 
margin is calculated per ref. (f). 


Case 1: Power Available = 200 W 

Max. Estimated Power Required = 249 W 

Power Margin = 100 (200 W - 249 W) / 249 W = -19.7% 

Case 2: Power Available = 200 W 

Max. Estimated Power Required = 151 W 

Power Margin = 100 (200 W - 151 W) / 151 W = 32.5% 


The margins for Cases 1 and 2 are - 19.7% and + 32.5%, respectively. Now consider a third case 
in which a designer rounds calculations to the first digit in Cases 1 and 2. 

Case 3: Power Available = 2 x 10 2 W 

Max. Estimated Power Required = 2 x 10 2 W 

Power Margin = 100 (2 x 10 2 W - 2 x 10 2 W) / 2 x 10 2 W = 0% 

The calculation for Case 3 shows zero margin and illustrates how rounding can have a significant 
effect on margin determination. From Fig. 4, the power margin at the end of pre-Phase A is 
required to be 30%. Comparing Case 3 with Case 2 shows this required 30% margin can be fully 
masked when rounding to the first digit. Additional rounding errors can accrue when combinations 
of rounded results are used to perform successive calculations. 

Document Study Results in Reports. Per ref. (h), formal trade studies should be well 
documented, i.e., “formal trade studies ...are typically well-documented and become part of the 
decision database normal to systems development". This guidance applies to concept design 
results, as concept design consists principally of formal trade studies. 

Design and trade study results should be documented in reports for each subsystem and discipline 
at end of each cycle. These reports provide the official study record of what team did, how the 
team did it, and what the team found for present (and future) team use. Built from standardized 
templates, their technical descriptions include analysis methods and example calculations. These 
reports enable effective: a) technical integration across subsystems and disciplines, b) system level 
review and integration, and c) independent review. They also provide coherent and comprehensive 
technical waypoints that enable team members to recall design and performance information from 
prior cycles that often is needed for design scaling or comparison. Absent such waypoints, the 
high rate of design changes in concept design makes recalling such information difficult. These 
technically functional (but not necessarily editorially pristine) reports typically are approved by, 
and maintained under informal configuration control of, the systems study engineer. Briefings 


often are too cursory to effectively serve these purposes. Briefings, if needed, may be quickly built 
from the approved reports and contain only information contained in the approved reports. 

Recognize Four Unofficial, but Typical, Phases of Concept Design. Concept design teams 
developing immature mission concepts that advance state of the art often experience four 
sequential phases of work. Recognizing and understanding these phases is key to guiding a team 
to determine a feasible concept design within the allotted study time and resources. 

1) Unbridled Optimism: This phase features unbridled, optimistic performance desires 
levied as “requirements” before a team gains a credible understanding of the associated 
cost and schedule implications. Meetings often are not well-focused on study objectives. 
Instead, they feature extended advocacy discussions (e.g., why the mission has the best 
science of all competing missions, why the mission has the best chance to win, etc.). 

2) Shock: This brief phase usually begins after a team completes its first credible cost 
estimate. 

3) Denial: This phase features abundant rationalizations as to why the models used for the 
cost estimate were not representative. A team points to any aspect of the mission - except 
the excessively high technical capability - as the reason costs are too high, so that science 
return remains compelling relative to that of the competition. 

4) Acceptance: This phase features the ultimate realization that technical capability / science 
return must be lowered to design a credible mission concept that meets cost and schedule 
constraints according to established independent review standards. 

Time spent in phases 1-3 usually is non-recoverable. Teams that dwell in these phases often 
experience significant overtime demands as they approach study completion on a fixed study 
timeline. The more quickly a team moves through Phases 1, 2 and 3, and arrives at Phase 4, the 
better that team is likely to fare. 


Closing Thoughts 

Given the extraordinary leverage concept design has in determining life cycle cost, there is a 
business case for conducting concept design in a rigorous and pragmatic fashion, particularly for 
immature mission concepts that advance state of the art and that have high design uncertainty. This 
paper provides specific techniques in trade space design and trade study execution to help achieve 
credible design-to-cost convergence with minimum expended time and effort. It introduces a level 
of quantification for the degree of convergence needed in the concept design product in the context 
of technical and programmatic resource margins available in preliminary design. It also identifies 
challenges that can mask credible convergence, including design and cost evaluation learning 
curves, unknown unknowns, and numerical errors. In addition, it provides techniques for selecting 
trade study cases that help manage those challenges and that promote objective concept evaluation, 
help reveal unknowns, and expedite convergence. 

The concept design phases provide a unique venue to facilitate exploring and converging the 
system level design. Done well, concept design can provide an executable system level design 
baseline for project teams in Phase B and later phases. When not done well, some of the work of 


the concept design phases usually will have to be done again. The later this realization occurs, the 
more expensive the resulting redesign is likely to be. 
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